IBIS Macromodel Task Group Meeting date: 03 November 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis * Jared James Google: * Zhiping Yang Intel: * Michael Mirmak Kinger Cai * Alaeddin Aydiner Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan * Todd Bermensolo Rui Yang Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: Randy Wolff * Justin Butterfield SAE ITC Jose Godoy SiSoft (Mathworks): Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark and Justin Butterfield took the minutes. -------------------------------------------------------------------------------- Opens: - Ambrish asked to reserve time to discuss his proposal to make PAM4 threshold parameters optional. Arpad agreed (discussion below). ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the October 27th meeting. Michael moved to approve the minutes. Jared seconded the motion. There were no objections. ------------- New Discussion: Redriver Flow Issues: Alaeddin reviewed his presentation, "Symmetric Synthesis of (the Essence of) Existing Re-driver Proposals". He noted that it contains his own personal opinions and suggestions. He noted several goals for the proposal: - Keep the non-EQ-adapting case as the default to preserve the existing simplicity of the implementation, given that nearly all (perhaps all) existing redriver models do not EQ adapt. - Extend the standard "symmetrically" so both Tx and Rx models can utilize additional inputs seen in earlier proposals if necessary. - Preserve the existing flows' requirement that AMI_Init() functions only need to be called once. - Allow multi-level redriver scenarios to be implemented by looping over the redrivers from initial Tx to final Rx. Slide 5: This further refines the notation conventions he introduced in the previous presentation. The index k denotes the kth redriver in the chain, and the post- channel for k is the same as the pre-channel for k+1. Slide 6: Alaeddin noted that in the normal AMI flow the Rx looks at a pre-channel IR, possibly equalized by the Tx. The Tx looks at its post-channel IR. For redrivers, we want to consider different IRs. We may want the Tx to modulate the upstream impulse rather than the downstream IR, for example. With redrivers, we can symmetrically continue to define pre and post per each redriver. Then, by default, a redriver TX processes its post-channel while a redriver RX processes its pre-equalized channel. Post-channels are unequalized again. Two new AMI reserved keywords to control the EQ-mode could be introduced to modify the default behavior (AMI_RED_TX_EQ_MODE and AMI_RED_RX_EQ_MODE). These "eq-mode" keywords would have "post (default), pre, both" for a redriver Tx and "pre (default), post, both" for a redriver Rx. If, for example, "pre" is set for a redriver TX, it would take its (equalized) pre-channel response. Likewise, if "post" is set for a redriver Rx, it would take its unequalized post-channel. In the case of "both", the impulse response matrices are appended with the missing "pre" and "post" impulse responses including crosstalk IRs. Because post-channels are always considered to be unequalized, AMI_Init invocations proceed from Tx to Rx and happen only once. Slide 7: This details the cases in tabular form. Alaeddin noted there are 9 possible cases. The functions can be derived for the 9 cases, but they are not shown for brevity. Slide 8: Alaeddin said he wants to check and confirm that each AMI_Init is called only once and make sure the chain of redrivers can be handled by simply iterating from left to right. Assuming there are no major issues, are the desired EQ adaptation features handled by this proposal? In terms of handling the Init-Only models in a redriver scenario GetWave simulation, Alaeddin thinks the proposal can handle the Init-Only IR changes by folding them into the IR of the nearest connected channel. The only exception to this is the case of a redriver model that combines the Tx and Rx into one. Alaeddin said this is a pathological case, and he wondered if the standard should not allow combined Tx-Rx redriver models. Arpad asked about the AMI_Init being called once and if it is possible to do what is proposed on slide 6. Alaeddin replied the post channel would continue to be used in this proposal. The redriver Rx would be invoked before the redriver Tx. When we have a redriver, we see its Rx first and then its Tx. The post IR is the unequalized impulse response. Arpad said that Walter had proposed a parameter to select the pre or post channel IR as the input to the Tx. Arpad thought there would be two IRs. Alaeddin stated, because we are only considering the channel with no equalization, we only need to invoke the AMI_Init once. Hansel asked if we are taking into account the non-linearity and if the source of the non-linearity is the IV curves or the AMI executable model. Alaeddin replied the non-linearities would be in the empirical (GetWave) signaling. Using the modified IRs in the AMI_Init calls allows for faster adaptation and reduction of the Ignore_bits for the GetWave calls. Arpad noted an email from Walter that had said that the existing flow works fine except for certain problematic combinations of Init-Only, GetWave-only, and Dual models. Alaeddin said he thought his proposal could handle Init-only models by lumping their contribution into the nearby channel. Aside from the pathological lumped Tx-Rx redriver model, which deprives us of a single channel connecting to each model, the contributions can be folded into the nearest neighbor channel. Ambrish asked to clarify that Alaeddin's slides were not discussing any GetWave portion of the flow. They were all concerned with AMI_Init calls and their modification of the IRs. Alaeddin agreed, though he reiterated that having all the IR contributions at AMI_Init time is very helpful for reducing Ignore_Bits in the GetWave flow. Ambrish said it would be helpful if Alaeddin could add some figures to show how the notation (pre, post, etc.) maps to the various portions of the channel. Alaeddin said he would add some pictures. Arpad shared a presentation from July 13, 2010 (ATM work archive) in which Todd Westerhoff had introduced a similar mathematical notation and enumerated 9 equations for the various combinations of model types. Fangyi noted one concern about the proposed notation. If the Rx modifies the IR and is applying DFE, then it's not convolution. He said the notation could be confusing on the Rx side for this reason. PAM4 threshold parameters discussion: Ambrish discussed the PAM4_UpperThreshold, PAM4_CenterThreshold and PAM4_LowerThreshold parameters (pg. 255, IBIS 7.0). He noted that the Required: field says "No", they are not required. However, the Usage Rules: state that if the Modulation parameter contains "PAM4" as a choice then PAM4_UpperThreshold and PAM4_LowerThreshold are required (PAM4_CenterThreshold defaults to 0.0V if it isn't declared). Ambrish suggested that we remove the language requiring the upper and lower thresholds. He said that providing these values may be a bit cumbersome for the model maker, and EDA tools typically have to compute the thresholds themselves anyway. If the model advertises that it returns them that's great, but the model shouldn't be required to return them. Ambrish said it's especially troubling if the model returns values that don't jive with the simulation results. It could cause problems for the tool. Ambrish said all EDA tools have to be able to come up with thresholds themselves anyway. Ambrish said the EDA tool could compute these values over the entire length of the simulation, where the model would be limited to computing them over the blocks of data it saw. Arpad summarized the email discussion from the ATM list. He said there's a publicly available algorithm to compute these thresholds from the IR, and tools can implement that or their own improved methods. So, the tool can do it. Arpad noted that he had run into a case where the model returned bad threshold numbers that were incompatible with the simulation results, and this had caused problems. Ambrish noted that in the email exchange Walter had said he was okay with making the parameters optional. Arpad said his issue is still the same, even if the parameters are optional. The model could still return incorrect threshold values, and the tool has to deal with it. Fangyi said that the tool should always use what the model returns. If the model returns something that is incorrect, then the model is bad. He said it's analogous to the CDR modeling. If the model returns clock ticks that are not close to the nominal value then the CDR failed, and the tool should not try to correct the model. You have no way of knowing what valid results would be. Fangyi said he too was okay with making them optional. However, he noted that Walter had also said that a good PAM4 model should always return the thresholds. Ambrish asked if the EDA tool wasn't better able to generate these thresholds. Fangyi said that in a physical device these thresholds are determined by the device, similar to the CDR. Fangyi said he had originally introduced these parameters so the model could return the thresholds as they varied over time. Curtis said if you're using a cookbook algorithm to compute the thresholds from the IR, then the EDA tool can do it just as well. However, if you want an idea of what the actual hardware is doing, then only the AMI executable model can provide that. Fangyi agreed. Ambrish noted that the model is not forced to return clock ticks, i.e., not forced to provide a model of the CDR. So, continuing that analogy it should also not be forced to provide these thresholds. Arpad asked if Ambrish wanted to draft a BIRD. Ambrish said he would work on drafting a BIRD. Arpad suggested that he enumerate the allowed combinations if they are all optional, for example, if the upper threshold is provided then the lower threshold must also be provided. Hansel suggested Ambrish make sure table 27 is updated if necessary. - Curtis: Motion to adjourn. - Michael: Second. - Arpad: Thank you all for joining. AR: None. ------------- Next meeting: 10 November 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives